The present invention relates to industrial controllers and in particular to an industrial controller system having a secondary controller providing back-up control capability. More particularly, the present invention relates to systems and methods for implementing hardware tracking in an industrial control system.
Industrial controllers are special purpose computers used for controlling factory automation and the like. Under the direction of stored programs, a processor of the industrial controller examines a series of inputs reflecting the status of a controlled process and changes outputs affecting control of the controlled process. The stored control programs may be continuously executed in a series of execution cycles, executed periodically, or executed based on events.
The inputs received by the industrial controller from the controlled process and the outputs transmitted by the industrial controller to the controlled process are normally passed through one or more input/output (I/O) modules which serve as an electrical interface between the controller and the controlled process. The inputs and outputs are recorded in an I/O data table in processor memory. Input values may be asynchronously read from the controlled process by specialized circuitry. Output values are written directly to the I/O data table by the processor, and then communicated to the controlled process by the specialized communications circuitry.
Industrial controllers must often provide uninterrupted and reliable operation for long periods of time. One method of ensuring such operation is by using redundant, secondary controller components (including processors) that may be switched in to replace primary controller components while the industrial controller is running. In the event of a failure of a primary component, or the need for maintenance of the components, for example, the secondary components may be activated to take over control functions. Maintenance or testing of the control program may be performed with the primary processor reserving the possibility of switching to the secondary processor (and a previous version or state of the control program) if problems develop.
Ideally, the switch-over between controllers or their components should occur without undue disruption of the controlled process. For this to be possible, the secondary processor must be running or waiting to run the same program (and maintaining its current state) and must be working with the same data in its I/O data table as in the primary processor. Although tracking data in the I/O data table is described, it should be understood that the data tracking may include tracking any other type of data, such as variables that are used in a program. Accordingly, although I/O data table is used herein, it should be understood that this data may include any data being tracked and modified by the processors in executing programs.
A hardware tracking table is implemented as a specialized memory where, as writes are done to memory, bits are set in the hardware tracking table with each bit corresponding to a block of bytes in memory. A primary controller can track some or all of its memory writes so that it can transfer that information to a secondary controller that is not actually running the programs, merely tracking which programs are being executed in the primary controller. Accordingly, if a failure occurs in the primary controller, the secondary controller assumes the primary controller's role.
In a multitasking environment, hardware tracking can become much more complicated. Traditionally, one large tracking table has been used to track all information. Using a large tracking table in a multi-tasking environment, it is difficult to track and distinguish between the changes made by a first process and the changes made by a second process. Further, higher priority tasks may send changes that lower priority tasks have made such that the tasks transferring the data to the secondary controller are slowed significantly.
As an example of a difficulty that can arise due to task preemption, a counter may have incremented in a lower priority task where the lower priority task has been preempted by a higher priority task. The higher priority task would send the incremented counter value to the secondary controller. If a switchover to the secondary controller occurred at that point, the lower priority task would re-increment the counter as the lower priority task is reset during the switchover since it did not complete in the primary prior to the switchover occurring.
All changes are tracked as a single group such that one program's data cannot be differentiated from another. Therefore, when a higher priority task preempts a lower priority task, the higher priority task may transfer any or all of the data that was changed by the lower priority task. This transfer may include a significant amount of data and may significantly slow the completion time for the high priority task. This is undesirable since high priority tasks are often time-critical and yet they become a vehicle for transferring a majority of the data changes.
What is needed is a system and method for implementing high priority tasks that decouples the data transfer of any task from the data changes made by other tasks. What is further needed is such a system and method where higher priority tasks transfer data associated with only completed lower priority tasks.